Due to the recent continuing increase in Internet usage, the number of potential targets for attacks against computer systems by malicious users has exploded. In order to find possible security loopholes in the numerous systems attached to worldwide communications networks, the parties seeking to break into networked computers have developed a good arsenal of powerful tools, which can systematically find resources available for suspicious activities. Together with the skills of the intruders this has proven to be extremely harmful for network security, even though it has given birth to a rapid growth of network security industry battling against the unauthorized use and eavesdropping of networked computers.
A typical example of a network in which intrusions and other unsolicited attacks may take place is shown in FIG. 1A. The core network is in this case the Internet 102, to which the hacker denoted by client 101 is connected. On one side of the Internet is a gateway element 103 separating a private network 104, such as a corporate LAN or intranet, from the Internet. The hosts connected to the Intranet, such as server 105, are the potential targets of intrusions or attacks.
Especially many service platforms running on servers attached to the Internet have shown their vulnerability to malicious users. As an example, many e-commerce systems used in the World Wide Web (WWW) have been attacked. This has caused both financial damages and severe problems regarding the misuse of confidential user data, such as credit card numbers or other sensitive information.
If the service platform does not meet high security standards, it is probable that it can be misused to get control over the system, to gain some classified information or at least to cause the system to crash. As an example, it can be expected that fixed parameters in a query string coming from a client have the same values as in the original Hypertext Transport Protocol (HTTP) stream sent to the client by the server. If an attacker changes the parameter values in an unexpected way, the system may start behaving in an odd way. The same applies to the lengths of the parameters that the client returns.
Web servers may have so-called directory traversal bugs, which notoriously can be exploited to retrieve a file not intended for the public. An example of this is an HTTP request typed in the location window of a web browser, such as http://www.sitename.net/../../../etc/password. The server may return the password file of a UNIX system as a response, the file being readily available for future decryption purposes.
Other common targets of attacks have been different Common Gateway Interface (CGI) binaries and scripts processing Hypertext Markup Language (HTML) forms. CGI is the standard for the environment passed by a server to scripts used in the WWW. Many CGI scripts have bugs, which may be directory traversal bugs or other flaws, such as shell-related and buffer overflow bugs.
Measures developed for tackling and/or noticing the security vulnerabilities or exploits in servers are, for example, security scanners and network intrusion detection systems (NIDS). Using some security scanners available it is possible to perform a vulnerability analysis of the server, which can detect the vulnerable parts of a service. In the analysis the CGI scripts within the system are scanned for known vulnerabilities. A NIDS is a silent listener, which monitors traffic flowing in the network and generates an alarm when something suspicious is detected in the traffic. The NIDS looks for regular expressions, and the matching is usually done for Ethernet frames, IP packets, or for the TCP stream. Fingerprints of known harmful HTTP requests may be used in looking for suspicious parameter values. Typically, HTTP requests and responses are checked as corresponding pairs, because one TCP connection typically carries one HTTP request response pair. The problem with using fingerprints is that they are vulnerable to even slight modifications of the request pattern used. In addition, the method is computationally heavy, as multiple fingerprints are needed when analyzing every single request. This has an adverse effect on the overall performance of the system.
An HTTP proxy which can filter the request-response pairs is another security solution. Unfortunately, it has the same limitations as the other solutions discussed above. FIG. 1B shows a simplified example of the generic action of a prior art HTTP proxy-gateway 151. The user agent 150 wishing to send a request to the web server 152 sends a request to the proxy. The proxy may cache some information, such as static web pages, in order to reduce the load caused to the server by incoming requests. The user agent, such as a web browser, first sends a TCP SYN packet 181 to the proxy in order to establish a connection. If the proxy allows the connection, it answers by sending a TCP SYN+ACK packet 182 in response. The user agent receives this and answers with a TCP ACK packet 183, thus finalizing the TCP three-stage handshake procedure. The host ID may be checked from the IP frame on which the TCP packets are carried. Similarly, the client ID may be verified from the TCP headers; such information may include target and destination port and so on. The user agent is ready to send an HTTP request 184, for example, a request for a web page containing information in a presentation language such as HTML.
The proxy opens similarly a TCP connection to the web server by sending messages 185-187, providing that the response for the request is not cached in the proxy, as it is, for example, when the HTTP data, such as HTML content, has some dynamic parts, such as forms or scripts. The proxy then sends the HTTP request 188 to the web server. The request 188 may essentially be similar to the original request 184. The server responds to the request by sending an HTTP response 189 to the proxy. The proxy then forwards the response to the user agent as a new HTTP response 190. The user agent may close the TCP connection by sending the TCP FIN+ACK packet 191, for which the proxy answers by sending first a TCP ACK packet 192 and then a TCP FIN+ACK packet 193. The proxy then closes the connection to the web server by sending a TCP FIN+ACK packet 194. The web server answers by sending first a TCP ACK packet 195 and then a TCP FIN+ACK packet 196.
Fingerprinting does not suit well for detecting attacks against the dynamic pages used widely in modern information systems. It is also possible that the connection between the user agent and the HTTP proxy persists. This means that the user agent does not close the connection between the HTTP proxy and the user agent after receiving the HTTP response 190, but may send further requests to the proxy.
None of the prior art solutions described above is able to detect unforeseen attacks against CGI binaries utilizing forms or scripts, for example. The prior art solutions also perform poorly in guarding the server against user-induced buffer overflows of fields of static length, such as the hidden select/option fields used in many HTML forms. In, other words, the prior art solutions fail to protect a server against unsolicited attacks and misuse attempts, made either purposely or by mistake in cases when the misuse is performed on a legal system port using formally correct queries but utilizing the weaknesses of the system.